Мы не раз писали об утилите RVTools, которая помогает в вопросах администрирования виртуальной инфраструктуры VMware vSphere (конфигурации и аудит). На днях вышло обновление этого средства - RVTools 3.7.
Автор утверждает, что скачано уже более 400 тысяч копий утилиты. Давайте посмотрим, что там появилось нового:
VI SDK поменяно с версии 5.0 на 5.5.
Увеличен таймаут при операции получения данных с 10 до 20 минут для окружений с большим числом хостов.
Новое поле VM Folder на вкладках vCPU, vMemory, vDisk, vPartition, vNetwork, vFloppy, vCD, vSnapshot и vTools.
На вкладке vDisk появилась информация Storage IO Allocation.
На вкладке vHost новые поля: service tag (serial #) и строка OEM-производителя.
На вкладке vNic новое поле: имя (distributed) virtual switch.
На вкладке vMultipath добавлена информация о доступе по нескольким путям.
На вкладке vHealth новая проверка: Multipath operational state (состояние доступа по нескольким путям).
Еще одна новая проверка vHealth: Virtual machine consolidation needed (машины, для которых нужно консолидировать снапшоты).
На вкладке vInfo новые поля: boot options, firmware и Scheduled Hardware Upgrade.
На статус-баре появилась дата и время последнего обновления данных.
На вкладке vHealth ошибки поиска датасторов видны как предупреждения.
Можно экспортировать csv-файлы через интефейс командной строки (как и xls).
Можно установить интервал автообновления данных.
Все время и дата отформатированы в формате yyyy/mm/dd hh:mm:ss.
Папки со временем и датой также создаются в формате yyyy-mm-dd_hh:mm:ss.
Bug fix: на вкладке dvPort теперь отображаются все сети.
Скачать RVTools 3.7 можно по этой ссылке. Документация доступна тут. Молодец автор - столько лет прошло, а утилита продолжает обновляться.
Как вы знаете, недавно вышла новая версия платформы виртуализации VMware vSphere 6.0, для которой было также обновлено средство создания кластеров хранилищ VMware Virtual SAN 6.0 на базе локальных дисков серверов. Среди прочих новых возможностей VSAN, было сказано об улучшении производительности решения, что и решили проверить коллеги на тестах вот тут.
Тест проводился дома и не претендует на какую-либо достоверность, но, все же, его весьма интересно посмотреть. Автор взял 3 узла Shuttle SZ87R6 следующей конфигурации (надо отметить, что они не в HCL):
Для тестирования были использованы следующие гипервизоры:
ESXi 5.5 Update 2 (build 2068190)
ESXi 6.0 (build 2494585)
В качестве средства создания нагрузки взяли IOmeter, размещенный в виртуальной машине с двумя vCPU, 4 ГБ памяти и Windows Server 2012 в качестве гостевой ОС. Было также сконфигурировано 2 дополнительных виртуальных диска на контроллере PVSCSI:
Для IOmeter было создано три профиля нагрузки, размер Working Set - 100 МБ (204800 секторов). Малый размер Working Set был выбран для более быстрого прогрева кэша.
Profile 1
Profile 2
Profile 3
Worker 1
vDisk 1
vDisk 1
vDisk 1
Sectors
204800
204800
204800
Outst. IO
16
16
16
Worker 2
vDisk 2
vDisk 2
vDisk 2
Sectors
204800
204800
204800
Outst. IO
16
16
16
Read
100%
0%
65%
Write
0%
100%
35%
Random
100%
100%
60%
Sequential
0%
0%
40%
Block size
4 KB
4 KB
4 KB
Alignment
4096 B
4096 B
4096 B
Результаты (кликабельно):
Как мы видим, VSAN 6.0 показал себя лучше при всех типах нагрузки - выжимает больше IOPS и имеет меньшую задержку (latency), а именно:
VSAN 5.5 (он же 1.0) использует формат vmfsSparse, который, по-сути, является redo-логом. В версии VSAN 6.0 появился новый формат снапшота vsanSparse, который использует механизм redirect-on-write (подробнее тут).
Тест проводился просто - запустили IOmeter (профиль 3) и последовательно снимали снапшоты, наблюдая производительность с помощью VSAN Observer.
Светло-серые картинки - это VSAN 1.0 (5.5), а темно-серые - VSAN 6.0 (кликабельно). Обратите внимание, что значения по осям X и Y на картинках не всегда соответствуют.
Итак, Latency:
Кстати, временами по latency VSAN 6.0 хуже своей предыдущей версии.
По IOPS результаты интереснее:
При создании нагрузки в виде снапшотов VSAN 6.0 снижает производительность по IOPS на 8%, а вот предыдущая версия VSAN - на 49%. Преимущества нового формата очевидны.
Полоса пропускания (Bandwidth):
Интересный эффект - в VSAN 1.0 существенно увеличивается трафик на чтение после снятия каждого снапшота, при этом у VSAN 6.0 такого не происходит. Еще одно улучшение Virtual SAN 6.0.
В целом можно отметить, что производительность кластеров VSAN заметно возрасла, ну а оптимизация снапшотов улучшит и производительность процессов, использующих эту технологию (например, резервное копирование).
Новых возможностей VMware vSphere 6.0 так много, что все они не уместятся в одной статье, поэтому приведем тут ссылки на наши заметки с описанием нового функционала платформы:
Как вы все знаете, в ближайшее время ожидается релиз новой версии платформы виртуализации VMware vSphere 6, где будет масса новых возможностей. Помимо, собственно, платформы, компания VMware выпустит также и обновленную версию пакета ПО для создания частного облака предприятия - VMware vCloud Suite 6.0. Не так давно стали известны подробности о составе и условиях лицензирования пакета - попробуем рассказать об этом.
Надо начать с того, что VMware vCloud Suite 6.0 состоит из следующих продуктов (как и прежде, лицензия - на процессоры хост-серверов ESXi):
VMware vCenter Site Recovery Manager - средство управления аварийным восстановлением на основе политик.
VMware vRealize Business - пакет решений для автоматического определения стоимости инфраструктуры и измерения потребления ресурсов.
VMware vRealize Automation - решение для автоматизации управления инфраструктурой и приложениями для сред vSphere на основе политик и в режиме самообслуживания.
VMware vRealize Operations - ПО для интеллектуального управления производительностью (мониторинг), ресурсами и конфигурациями.
Напомним, что о решениях семейства vRealize мы писали вот тут и тут, а также тут. Под брендом vRealize компания VMware объединяет все решения, предназначенные для управления гибридной инфраструктурой, в том числе средства управления ресурсами на стороне облачных провайдеров (не только VMware), а также средства управления инфраструктурами на базе различных гипервизоров.
Те, кто читал нашу статью о составе пакета VMware vCloud Suite 5.8, помнят, что в нем были две вещи, которые пропали в версии 6.0:
Теперь во все издания vCloud Suite входит решение vRealize Automation (имя издания соответствует изданию vCloud Suite), а в издания vCloud Suite Advanced и Enterprise - решение vRealize Business Standard:
Давайте посмотрим на возможности vRealize Business Standard в сравнениями с более продвинутыми изданиями этого решения (кликабельно):
Ранее vRealize Business Standard назывался IT Business Management Suite, и о нем мы немного писали вот тут. Это решение нужно для биллинга в виртуальной среде, когда вы знаете почасовую стоимость ваших ресурсов (старички помнят его еще как продукт vCenter Chargeback). С тех пор он весьма неплохо нарастил функционал.
vCenter Networking and Security (vCNS) - это решение также пропало из состава пакета VMware vCloud Suite 6.0. Когда-то vCNS был универсальным решением по обеспечению безопасности для платформы vSphere 5.1 и облачной инфраструктуры под управлением vCloud Director. Теперь же его функции взяла на себя и расширила платформа VMware NSX (она не входит в состав пакета и приобретается отдельно - но со скидкой для пользователей vCloud Suite).
Многих интересует вопрос - в связи с тем что vCNS снимается с продаж, будет ли возможность развертывать интерфейс безопасности vShield Endpoint? Ответ прост - vShield Endpoint является функцией vSphere. Будет возможность скачать и использовать vShield Manager / vCNS Manager только для установки и администрирования vShield Endpoint. Его функции будут лицензироваться ключом к vSphere. Другие функции vCNS будут недоступны.
Что касается состава пакета и лицензирования - на этом все. В следующих заметках мы расскажем о новых функциях компонентов, как станут известны подробности. Добавим, что есть документ на русском языке "VMware vCloud Suite 6.0 - Лицензирование, цены и комплектация", в котором приведено некоторое количество дополнительной информации о данном пакете продуктов.
Продолжаем рассказывать о новых возможностях платформы виртуализации VMware vSphere 6, выход которой ожидается в самое ближайшее время. Сегодня мы расскажем о поддержке режима vGPU, который позволяет предоставить ресурсы видеокарты (GPU) напрямую сразу нескольким виртуальным машинам (режим vGPU). Напомним, что эта технология уже довольно давно поддерживается в продуктах Citrix (а также в решении RemoteFX от Microsoft), а ее поддержка в платформах VMware была анонсирована в прошлом году на VMworld 2014.
Технология vGPU от NVIDIA при использовании с продуктами VMware подразумевает использование в качестве платформы VMware vSphere 6, а в качестве средства управления виртуальными ПК - VMware Horizon 6 (для этого выйдет специальное обновление с версией 6.1).
vGPU поддерживается для графических адаптеров NVIDIA GRID K1 и K2, для каждой из которых определены 4 профиля для виртуальных ПК, которые используют ресурсы видеокарты. Вот таблица этих профилей:
Всего есть три типа пользователей:
Designer - человек, который использует очень требовательные к графическим ресурсам приложения (не только дизайнеры, но и пользователи CAD-приложений).
Power User - человек, использующий подобные приложения время от времени.
Knowledge Worker - пользователь со сравнительно небольшой нагрузкой на ресурсы видеокарты.
Важно, что в рамках одного физического GPU видеокарты можно использовать только профили одного типа. Взгляните на картинку - как можно, а как нельзя:
Опишем здесь вкратце процедуру настройки использования vGPU с VMware vSphere 6, которая приведена в vGPU Deployment Guide (документ еще не вышел).
Для настройки vGPU необходимы следующие компоненты:
VMware vCenter 6.0
VMware ESXi 6.0
VMware Horizon View 6.1
NVIDIA GRID vGPU Manager
Потребуются также настройки BIOS на серверах (для каждого вендора свои). Вот, например, конфигурация Cisco:
CPU Performance: выставить в Enterprise или High Throughput.
Energy Performance: выставить в Performance.
PCI Configuration: выставить MMCFG BASE в 2 GB и Memory Mapped I/O above 4GB: Disabled.
VGA Priority: выставить в Onboard VGA Primary.
Далее нужно развернуть на хостах компонент NVIDIA vGPU Manager, который создает связь между GPU видеокарты и виртуальной машиной. Устанавливается он как обычный VIB-пакет:
После того, как NVIDIA vGPU Manager настроен на хост-серверах ESXi, нужно подготовить виртуальные машины. Делается это через vSphere Web Client. Выберем аппаратные характеристики ВМ в зависимости от типа рабочей нагрузки:
Затем в настройках ВМ нужно добавить Shared PCI Device:
Выбираем тип NVIDIA GRID vGPU и профиль в соответствии с таблицей, приведенной в начале статьи:
Обратите внимание, что нужно зарезервировать память для виртуальных машин, иначе их просто нельзя будет запустить. То есть, кнопку "Reserve all memory" нужно нажать обязательно. Кроме того, для машин, использующих vGPU, не поддерживаются такие технологии как vMotion, HA, снапшоты - то есть, машина полностью привязана к хосту ESXi.
После этого в виртуальном ПК можно устанавливать гостевую ОС (поддерживается Windows 7 и более поздние версии). Затем нужно установить NVIDIA GRID driver (после этого неплохо бы сделать из такой машины шаблон для дальнейшего ускоренного развертывания новых десктопов):
Кстати, в диспетчере устройств в гостевой ОС виртуального ПК можно посмотреть на драйвер графического адаптера:
Затем нужно соответствующим образом настроить пул виртуальных ПК в VMware Horizon View. Просто указываем протокол PCoIP и тип 3D-рендера NVIDIA GRID VGPU:
Вот, в принципе, и все. После этого виртуальные машины готовы к работе с vGPU в рамках пула виртуальных ПК.
Продолжаем рассказывать о новых функциях платформы виртуализации vSphere 6.0 (для этого у нас есть специальная страница). Сегодня у нас на очереди функции сжатия данных в VMware vSphere Replication 6.0. Функция репликации включена во все издания VMware vSphere, начиная с Essentials Plus (то есть, за бортом только Essentials). Кстати, родственная репликации функция резервного копирования VMware Data Protection 6.0 также есть во всех изданиях, начиная с Essentials Plus.
Начнем с того, что vSphere Replication 6.0 полностью совместима с продуктами VMware Virtual SAN 6.0 и vCenter Site Recovery Manager (SRM). Также в vSphere 6.0 появилась функция сжатия данных сетевого трафика при передаче:
Это снижает требования к ширине канала репликации, что особенно актуально при использовании продукта VMware SRM для обеспечения отказоустойчивости на уровне помещений или датацентров. Делается сжатие средствами библиотеки FastLZ, однако сжатие выключено по умолчанию.
При передаче данных репликации пакеты остаются сжатыми до того момента, пока они не отправляются на запись на диск. Но в некоторых случаях, в зависимости от версий ПО и особенностей архитектуры, сжатие может быть не на всем участке пути данных, или его может не быть вовсе. Пример: репликация vSphere 6.0 при соединении с виртуальным модулем vSphere Replication 5.8 - сжатия не будет. Если же, например, данные хоста ESXi 6.0 идут на виртуальный модуль vSphere Replication 6.0, а дальше на хранилище хоста vSphere 5.5, то данные будут разжаты на виртуальном модуле репликации, а дальше пойдут в обычном виде. Отсюда мораль - старайтесь поддерживать актуальные версии своего ПО на всех компонентах инфраструктуры.
В большинстве случаев достигается коэффициент сжатия данных в диапазоне от 1.6 к 1 до 1.8 к 1. Это приводит к уменьшению времени синхронизации и возможности настройки более строгой политики RPO.
Примеры:
1. ВМ с гостевой ОС Windows и диском в 37.5 ГБ при первой репликации без компрессии синхронизируется за 52 минуты. Когда включили компрессию, 20.2 ГБ данных отреплицировалось за 29 минут. Таким образом, эффективное использование канала выросло с 98 Mbps до 177 Mbps.
2. ВМ с гостевой ОС Linux и 4.7 ГБ данных при первичной репликации синхронизировались за 13 минут. После включения компрессии 2,8 ГБ ушли за 8 минут. Эффективное уменьшение ширины канала - с 49 Mbps до 80 Mbps.
Из минусов - компрессия создает нагрузку на процессор, поэтому нужно ее использовать аккуратно, и потому она отключена по умолчанию. Больше информации о технологии репликации от VMware можно найти в документе "VMware vSphere Replication 6.0 Technical Overview".
Мы много пишем про новые возможности платформы виртуализации VMware vSphere 6, релиз которой должен состояться уже в ближайшее время. Напомним наши последние посты:
Но и компания VMware тоже старается от нас не отставать. Например, недавно она объявила о доступности вебинара "Новинки vSphere 6" на русском языке, который можно в любое время посмотреть по запросу.
Многовато болтовни в начале, но для тех, кто готов слушать о VMware от VMware - почему бы и нет.
Мы уже немало писали про технологию Transparent Page Sharing (TPS) в VMware vSphere, которая позволяет дедуплицировать страницы оперативной памяти на хост-сервере ESXi при недостатке физической памяти для виртуальных машин. Как мы уже писали тут и тут, в VMware vSphere 5.5 Update 3 и более поздних версиях технология TPS отключена (при дедупликации страниц между машинами), чтобы не нагружать хост понапрасну, поскольку в современных ОС используются большие страницы памяти (Large Memory Pages), вероятность дедупликации которых мала. В то же время, технологию TPS никто из vSphere не убирал, и ее можно в любой момент включить.
Как пишет знаменитый Дункан, В VMware vSphere 5.x есть 4 состояния памяти для хост-сервера относительно параметра minFree:
High (100% от minFree)
Soft (64% от minFree)
Hard (32% от minFree)
Low (16% от minFree)
Эти состояния определяют срабатывание определенных триггеров (об этом ниже). Например, если minFree для вашей конфигурации сервера равно 10 ГБ, то при переходе в состояние, когда занято 6,4 ГБ (Soft), произойдет определенное действие с точки зрения техник оптимизации памяти.
В то же время, триггеры не срабатывают жестко по этим пороговым значениям, а плавно включаются перед ними и плавно выключаются за ними, чтобы не вызвать резких изменений.
Например, при переходе из состояния High в Soft, большие страницы памяти "разламываются" на обычные, чтобы TPS мог их тут же дедуплицировать. Однако, это может сказаться не лучшим образом на производительности - у хоста и так возникает недостаток памяти, а тут еще его нагружают дедупликацией.
Поэтому в VMware vSphere 6.0 ввели новое состояние Clear (100% от minFree), а состояние High переопределили до значения 400% от minFree. Для чего это сделано? А вот для чего.
При недостатке памяти, хостом ESXi используется техника разламывания больших страниц памяти на обычные страницы, которые затем могут быть дедуплицированы с помощью TPS. Это делается затем, чтобы предотвратить свопирование страниц на диск, что является самым тормозным способом освобождения ресурсов. Так вот эта штука начинает активно работать при наличии свободной памяти в промежутке от High (400%) до Clear (100%), чтобы начать работать на еще не испытывающем острого недостатка ресурсов хосте. Но при этом TPS сразу не запускается.
Давайте посмотрим на таблицу:
Состояние памяти (State)
Пороговое значение (% от minFree)
Эффект при переходе в диапазон
High
400%
Большие страницы разламываются на обычные, но TPS не запускается и ждет следующего цикла прохода дедупликации (по умолчанию 60 минут, минимально настраиваемое в расширенном параметре Mem.ShareScanTime время равно 10 минут)
Clear
100%
Разламывание больших страниц и мгновенный запуск TPS
Soft
64%
Включение TPS и техники Memory Ballooning
Hard
32%
Включение TPS, Memory Compression и свопирования на диск
Low
16%
Memory Compression + свопирование на диск + блокировка использования памяти
Это красивое решение - начать разламывать страницы заранее и не нагружать теряющий свободную память хост.
Но все что касается TPS, актуально только тогда, когда TPS включено. По умолчанию же эта техника выключена, а о том, как включить ее, написано вот тут.
Продолжаем вас знакомить с новыми возможностями платформы виртуализации VMware vSphere 6, которая еще не вышла, но про которую уже все что можно написано. Напомним и наши посты на эту тему:
Теперь на очереди улучшения хранилищ, а именно - возможность работы по протоколу NFS версии 4.1, которую ожидали очень долго (еще со времен ESX 3 хост-серверы работают с хранилищами по протоколу NFS 3). Об этом написал Cormac Hogan, являющийся экспертом в области инфраструктуры хранилищ VMware vSphere.
Итак, начать нужно с того, что при монтировании тома NFS на хосте ESXi важно использовать одну версию протокола, так как если один хост смонтирует том как NFS 3, а другой этот же том как NFS 4.1 - последствия для данных этого тома могут оказаться очень печальными (данные будут повреждены). Это во многом потому, что третья версия протокола использует клиентские блокировки (client side co-operative locking), а 4.1 - блокировки на стороне сервера (server-side locking).
Поэтому самый надежный метод - на хранилище разрешить использовать для тома только одну версию протокола NFS. Ну и соответственно при монтировании папки надо указать правильную версию протокола, везде одинаково:
Ну а теперь возможности при работе vSphere 6.0 с общими ресурсами NFS 4.1:
1. Multipathing и Load-blanacing
Протокол NFS 4.1, помимо улучшений производительности, имеет встроенные возможности доступа по нескольким путям и балансировки нагрузки.
В списке Servers to be added можно плюсиком из поля выше ввести список из нескольких IP-адресов серверов кластера для обеспечения балансировки нагрузки по нескольким путям. Ранее такое было доступно только для протокола iSCSI.
Отмечается, что поддержки pNFS (Parallel NFS) в VMware vSphere 6.0 нет.
2. Поддержка аутентификации Kerberos.
В NFS 3 добавлять папки нужно было только под пользователем root, соответственно на хранилищах нужно было везде включать настройку no_root_squash, что не очень-то безопасно.
В NFS 4.1 можно создать нерутового юзера для папок, а на хостах нужно создать специального пользователя следующей командой:
esxcfg-nas -U -v 4.1
Везде на хостах ESXi, имеющих доступ к одним и тем же NFS-ресурсам должны быть добавлены одинаковые пользователи. Если пользователи разные, то у вас, например, не пройдет vMotion (вывалится с ошибкой).
Чтобы возможность аутентификации Kerberos работала, нужно чтобы все хосты ESXi были введены в домен Active Directory (об этом написано на скриншоте, у восклицательного знака).
3. Работа NFS 4.1 с другими технологиями VMware.
К сожалению, поддержка NFS 4.1 в vSphere 6.0 неполная - такие хранилища не поддерживаются для следующих технологий и продуктов VMware:
Storage DRS
Storage I/O Control
Site Recovery Manager
Virtual Volumes
При этом функции кластеров высокой доступности HA и балансировка нагрузки DRS полностью поддерживается. Ну и отметим тут, что IPv6 поддерживается для доступа по протоколу NFS 4.1, однако только в режиме AUTH_SYS (то есть без аутентификации Kerberos).
Как все из вас знают, скоро выходит обновленная платформа виртуализации VMware vSphere 6, в которой появилась уйма новых возможностей. О многих из них мы уже писали (см, например, нашу последнюю заметку тут). На днях компания VMware сделала еще одну полезную вещь - выложила пошаговые гайды по некоторым компонентам vSphere 6 на сайте VMware Feature Walkthroughs.
Напомним, что про эти гайды мы уже писали тут и тут. Эти штуки позволяют в интерактивном режиме пройти по шагам конфигурации различных продуктов в интерфейсе соответствующего решения. То есть, все так же, как вы будете нажимать в vSphere Web Client:
Какие гайды доступны уже сейчас:
vCenter Server Install - установка компонентов vCenter 6.0. Напомним, что о новых функциях в vCenter мы писали вот тут.
vCenter Server Upgrades - процесс обновления со старых версий vCenter Server, включая 5.x, до версии vCenter 6.0.
vSphere Data Protection – набор пошаговых гайдов, позволяющих пройти весь процесс резервного копирования виртуальных машин. О новых возможностях VDP 6.0 мы также писали вот тут.
vSphere Replication – эти гайды позволят вам самостоятельно настроить репликацию и попробовать повосстанавливать виртуальные машины из реплик.
В ближайшее время ожидаются новые Feature Walkthrough - следите за обновлениями!
Продолжаем рассказывать о возможностях новой версии серверной платформы виртуализации VMware vSphere 6, выход которой ожидается в ближайшее время. Напомним наши последние посты на эту тему:
Сегодня у нас на очереди одна из самых интересных тем в vSphere 6 - технология организации хранилищ VMware vSphere Virtual Volumes (VVOls). Напомним, что ранее мы подробно писали о ней тут. С тех пор появилось некоторое количество новой информации, которую мы постараемся актуализировать и дополнить в этом посте.
Начнем с того, что vVOL - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. vVOLs - это новый способ организации хранилищ в виде удобном для массива, когда используется не традиционная файловая система VMFS, а массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин.
Тома vVOLs создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы сейчас видите в папке с ВМ, создается отдельный vVOL. В итоге же, создаются следующие тома на хранилище:
1 config vVOL создается для метаданных ВМ, он включает в себя конфигурационный файл .vmx, дескрипторные vmdk для виртуальных дисков, лог-файлы и прочие вспомогательные файлы.
1 vVOL создается для каждого виртуального диска .VMDK.
1 vVOL создается для файла подкачки, если это требуется.
1 vVOL создается для каждого снапшота и для каждого снимка оперативной памяти.
Дополнительные тома vVOL могут быть созданы для клонов или реплик виртуальной машины.
Давайте посмотрим на архитектуру VVols:
Здесь мы видим следующие компоненты:
Storage Provider (SP)
Технология vVOLs при взаимодействии с аппаратным хранилищем реализуется компонентом Storage Provider (SP), который также называется VASA Provider (подробнее об интерфейсе VASA - тут). Storage provider - это предоставляемый вендором аппаратного обеспечения слой ПО, который обеспечивает взаимодействие платформы vSphere и, собственно, хранилища с организованными на нем томами vVOLs в виде контейнеров (storage containers). vVOLs используют механизм VASA 2.0, который позволяет управлять объектами виртуальных машин (дискми) прямо на хранилище.
Protocol EndPoint (PE)
Если раньше каждый хост налаживал в случае необходимости соединение с каждым из vmdk-дисков виртуальных машин и получалось куча связей, то теперь у хранилища есть логическое I/O-устройство, через которое происходит общение с томами vVOL. PE можно считать сущностью, пришедшей на замену LUN, этих PE может быть создано сколько угодно (кстати, длина очереди у PE - 128 по умолчанию, вместо 32 у LUN).
То есть, через PE хост ESXi получает доступ к данным конкретной виртуальной машины. PE совместимы с существующими протоколами FC, iSCSI и NFS и позволяют использовать уже имеющееся ПО для управления путями в SAN. К отдельному PE через vCenter можно привязать или отвязать тома vVOL отдельных виртуальных машин. Для хранилища не нужно много PE, одно это логическое устройство может обслуживать сотни и тысячи виртуальных томов vVOL.
Storage Container (SC)
Это логическая сущность, которая нужна для объединения томов vVOL по типам в целях выполнения административных задач. Storage Container создается и управляется на стороне дискового массива и предназначен для логической группировки и изоляции виртуальных машин (например, виртуальные машины отдельного клиента в публичном облаке vCloud).
vVOL Datastore
Это хранилище, которое непосредственно создается из vSphere Client. По-сути, это представление Storage Container (SC) для платформы VMware vSphere. Этот тип датастора можно, например, выбрать при создании виртуальной машины:
С точки зрения администрирования, эти датасторы аналогичны VMFS-томам - вы так же можете просматривать их содержимое и размещать там виртуальные машины. Но для них недоступны операции расширения или апгрейда - они полностью контролируются со стороны дискового массива.
Policy Based Management
Это механизм, который позволяет назначать виртуальным машинам политики, которые определяют ее размещение, а как следствие, и производительность с точки зрения подсистемы ввода-вывода (например, можно задавать необходимые трешхолды по ReadOPs, WriteOPs, ReadLatency и WriteLatency.).
Дисковый массив на базе этих политик позволяет разместить виртуальную машину на нужном хранилище и обеспечить необходимые операции по обеспечению нужного уровня производительности.
По прочтении этого материала возникает вопрос - а чем vVOLs лучше механизма VAAI, который уже давно существует для VMware vSphere? Ответ прост - это замена VAAI, которая позволяет еще больше функций по работе с виртуальными машинами и организации хранилищ переложить на сторону аппаратного обеспечения. В случае невозможности операций с vVOLs будет произведено переключение на использование примитивов VAAI:
Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.
Не так давно мы писали о новых возможностях решения для отказоустойчивости хранилищ VMware Virtual SAN 6.0, которое выйдет вместе с новой версией платформы виртуализации VMware vSphere 6. Одной из таких новых возможностей стал режим All-Flash Configuration, когда хост-сервер ESXi использует только SSD-накопители. При этом быстрые и надежные накопители используются для целей кэширования (cache tier), а устройства попроще - для хранения данных (capacity tier).
Чтобы использовать конфигурацию All-Flash нужно специальным образом пометить диски хост-серверов ESXi для яруса Capacity Tier. Сделать это можно через консоль RVC, либо через интерфейс ESXCLI на каждом из хостов.
Так, например, это делается через RVC:
А вот последовательность команд ESXCLI:
Получается, что на каждом из хостов кластера Virtual SAN администратор должен с помощью CLI-интерфейса обозначать диски, которые будут использоваться для создания яруса хранения виртуальных машин. Жутко неудобно.
Кстати, узнать о том, входит ли конкретный диск в Capacity Tier можно с помощью команды VSAN Disk Query (vdq):
# vdq -q
Так вот, коллеги с punchingclouds.com делают утилиту с GUI, которая позволит назначать дисковым устройствам на хостах ESXi это свойство быстро и удобно, экономя часы времени (представьте, что у вас 64 узла в кластере, на каждом из которых по 10 SSD-дисков, то есть надо назначить 640 дисков!).
Для начала работы надо ввести данные учетной записи VMware vCenter, а также пользователя на хостах VMware ESXi. Минус тут в том, что пароль на всех хостах должен быть одинаковый (но это обещают исправить в следующей версии, сделав загрузку csv-файла с паролями).
Перед тем, как приступить к операциям с дисками, нужно включить SSH на хостах ESXi (настройка на хостах происходит через ESXCLI), делается это кнопкой "Enable SSH". Далее можно сгруппировать похожие устройства по хостам или кластеру, после чего отметить нужные устройства в списке дисков.
Ну и далее нажимаем кнопку "Set Capacity Flash", чтобы назначить диски для хранения виртуальных машин, или "Remove Capacity Flash", чтобы отвязать их от этой роли.
Утилита VMware VSAN All-Flash Configuration Utility скоро будет доступна, следите за обновлениями здесь.
Мы уже весьма немало писали про возможности обновленной версии платформы виртуализации VMware vSphere 6, в которой будет настолько много новых фичей, что мы не можем перечислить их все в одной статье. Поэтому мы делаем это по частям:
В этой части мы расскажем о новых возможностях платформы vSphere с точки зрения улучшений, сделанных непосредственно в плане хостов ESXi и виртуальных машин.
Итак, начнем по порядку:
1. Новые возможности хост-сервера и кластера.
Если еще с давних времен кластеры VMware HA/DRS объединяли 32 хоста, то в версии vSphere 6 кластер, наконец-то, может объединять до 64 хостов включительно. Помимо этого, на хосте может быть запущено до 1000 виртуальных машин (и до 8000 в кластере), а сам ESXi поддерживает сервер с числом процессоров до 480 CPU и памятью до 12 ТБ.
Сравним с предыдущей версией:
2. Новые возможности виртуальных машин.
Виртуальные машины, как и хосты ESXi, также стали поддерживать еще большие максимальные конфигурации - теперь можно создать машину со 128 vCPU и до 12 ТБ оперативной памяти:
Интересны также и другие возможности. Горячее добавление памяти теперь правильно работает с vNUMA, что положительно сказывается на производительности. Появилась поддержка ускорения для объектов GDI в пакете драйверов WDDM 1.1, также контроллер xHCI 1.0 теперь работает с драйвером этого контроллера под Мак, начиная с OS X 10.8.
3. vMotion теперь работает между разными vCenter и на большие расстояния.
В VMware vSphere 6 технология горячей миграции виртуальных машин vMotion была значительно улучшена. Во-первых, виртуальные машины могут теперь перемещаться между виртуальными коммутаторами Standard vSwitch и Distributed vSwitch в любой их комбинации, при этом при уходе с vDS настройки машины на его портах сохраняются и уезжают вместе с ней.
Во-вторых, теперь виртуальные машины могут перемещаться между датацентрами с разными серверами vCenter (требуется лишь соединение на уровне L2). При переезде адрес виртуальной машины сохраняется и нарушения функционирования сети не происходит. Настройки машины также уезжают вместе с ней:
MAC-адреса всегда будут уникальными даже на разных vCenter, а когда машина приедет обратно - ее адрес не будет занят.
При этом для миграции не требуется ни общего хранилища, ни той же самой сети или того же vCenter - можно все это в рамках одной операции vMotion поменять:
Кроме того, если раньше vMotion "держала" задержку в канале (RTT) до 10 мс (и до 50 мс в Enterprise Plus издании), то теперь это значение увеличено до 100 мс. То есть, стратегия Follow the sun для перераспределения нагрузки - теперь реальность, так как такое RTT позволяет уже "трансконтинентальные" миграции vMotion:
Интересно, что с помощью такого vMotion можно, например, увести машины из датацентра в местности, где начинается ураган, который все обесточит - и при этом все это будет незаметно для пользователей (почти).
4. Полезные мелочи.
Во-первых, появилась настройка политики сложности пароля в Host Advanced System
Settings. Раньше для этого нужно было мудохаться с pam.d модулем.
Во-вторых, в логах хостов ESXi действия, произведенные через vCenter, включают в себя пользователя, которых их выполнял. Если раньше в логе было так: [user=vpxuser], то теперь вот так: [user=vpxuser:DOMAIN\User]. Весьма удобно.
Улучшенный механизм vSphere Network I/O Control версии 3 позволяет гарантировать уровень обслуживания на уровне vNIC виртуальной машины. Применять NetIOC можно также и к Distributed Port Group:
На этом вкратце все. Ну и так для общей информации - улучшения режима Linked Mode для серверов vCenter:
Продолжаем знакомить наших читателей с новыми возможностями платформы виртуализации VMware vSphere 6, релиз которой должен состояться уже совсем скоро. Напомним наши предыдущие посты на эту тему:
Сегодня у нас на очереди VMware vSphere 6 Web Client. Главная новость как раз об отсутствии нового - веб-клиент, по-прежнему, работает на Flash, никакого HTML5 - и это досадно. Поэтому в комментариях и пишут, что новый клиент - это "lipstick on a pig", то есть косметические улучшения без переработки по существу.
Но есть и хорошая новость - VMware уверяет, что новый клиент работает в пять раз быстрее прошлого:
Посмотрим на тесты:
Действительно, в каких-то отдельных случаях работает в 5 и более раз быстрее. Ну ок, давайте пройдемся по новым фичам:
1. Контроль производительности раздела "All Users’ Tasks".
Если раньше эта штука в панели Recent Tasks грузилась очень долго, особенно в инфраструктурах, где сервер vCenter обслуживал много хостов ESXi и пользователей, то теперь она отключена по умолчанию, чтобы не создавать нагрузки. Включить ее можно вручную, в следующем файле на сервере vCenter:
Для vCenter Server Appliance используйте этот конфиг-файл:
/etc/vmware/vsphere-client/webclient.properties
Меняем строчку show.allusers.tasks=false на show.allusers.tasks=true (перезагрузка не требуется).
Теперь все таски пользователей будут показываться в разделе All Users’ Tasks.
2. Множество улучшений производительности.
Производительность была целью номер один в новой версии vSphere 6 Web Client. Были переработаны следующие разделы:
Страницы Login (в 13 раз быстрее!) и Home
Страницы Summary
Страницы Networking
Списки Related Objects
Общая навигация по разделам
Графики производительности (Performance Charts - в 2 раза быстрее)
Контекстные меню действий по правой кнопке (Action Menu - в 4 раза быстрее!)
3. Таски и гибкое размещение панелей.
Теперь список задач удобно размещен внизу:
Сами панельки можно отлеплять и ресайзить:
4. Реорганизованные Action Menu.
Теперь в меню, вызываемых по правой кнопке, все действия размещены на нужных и интуитивно понятных местах, а сами действия не тянут при прорисовке лишних данных, что увеличивает производительность клиента:
5. Новое меню по кнопке Home.
Теперь из него можно попасть в наиболее часто используемые разделы:
6. Возможность убрать предупреждение о включенном SSH прямо из GUI.
Появилась так давно нужная ссылка Suppress Warning:
7. Возможность поместить алармы и таски на правую панель.
Очень удобно:
8. Ну и гора всяких мелочей.
Типа совместимости с прошлой и новой версией Fault Tolerance:
Самое обидное, что Web Client, по-прежнему, несовместим с VMware Update Manager - можно просматривать его задачи, но запускать Remediate нельзя.
Ну и напоследок полезная ссылка про трюки в vSphere Web Client, вам может оказаться очень полезной - http://tiny.cc/webclientwiki.
Все из вас знают, что недавно компания VMware анонсировала обновленную версию платформы VMware vSphere 6. Ввиду того, что новых функций уж очень много, мы решили разбить описание новых возможностей продуктов серверной линейки на несколько постов. Напомним последние из них:
Сегодня мы поговорим об анонсированной новой версии VMware vSphere Data Protection 6.0 (VDP) - продукте для резервного копирования виртуальных машин на серверах ESXi. Если ранее пользователям предлагалось одно из двух изданий - встроенное в платформу и vSphere Data Protection Advanced (с расширенными функциями), то теперь осталось только одно. Теперь VDP включено во все издания VMware vSphere, кроме самого базового (Essentials). То есть, пользователи vSphere 6.0 Essentials Plus и более старших изданий получат VDP в комплекте. Кстати, продукт vSphere Data Protection Advanced будет недоступен для заказа с 1 марта.
Напомним, что VDP построен на базе решения для резервного копирования и дедупликации EMC Avamar, которое развертывается как готовый виртуальный модуль (Virtual Appliance). ПО работает без агентов, использует функциональность Changed Block Tracking и может восстанавливать не только машины целиком, но и отдельные файлы из бэкапов через браузер. Шестая версия VDP поддерживает до 8 ТБ дедуплицированных данных бэкапов.
Итак, что нового появилось в VDP:
1. Агенты для Microsoft SQL Server, Exchange и SharePoint.
Напомним, что это намного раньше появилось в Veeam Backup and Replication, а теперь VMware "заимствует" функциональность у Veeam. Эти агенты позволяют создавать консистентные копии виртуальных машин с данными приложениями, а также восстанавливать отдельные объекты приложений из бэкапов (например, базу данных или электронное письмо). Агенты поддерживают такие функции, как SQL Server Failover, кластеры AlwaysOn и Exchange Database Availability Groups.
2. В VDP появилась интеграция с хранилищем EMC Data Domain с использованием ПО Data Domain Boost.
Теперь за обработку бэкапов может отвечать Data Domain, а модуль VDP просто отвечать за передачу данных. Данная функция также есть у Veeam.
3. Возможность репликации данных между модулями VDP.
Данные, передаваемые между модулями VDP дедуплицируются, поэтому в канал передаются только уникальные блоки данных. Это может оказаться необходимым при отбрасывании резервных копий на резервные хранилища через WAN. При этом поддерживаются различные топологии репликации данных виртуальных модулей - 1:1, N:1 и 1:N.
4. Сжатие данных для vSphere Replication.
Теперь если вы используете VMware SRM для репликации данных между площадками и восстановления машин после сбоев, то при передаче данных включается технология сжатия данных при передаче (end-to-end network compression).
Типичный коэффициент сжатия данных - от 1.6:1 до 1.8:1. Например, если раньше машина размером 37.5 ГБ передавалась за 52 минуты, то теперь она ужимается до 20.2 ГБ и передается за 29 минут.
5. Улучшенная репликация.
Теперь неаллоцированные регионы данных не гоняются по каналу репликации, что увеличивает ее скорость. Поддерживаются тонкие диски и устройства Virtual SAN.
6. Верификация резервных копий.
Теперь резервные копии VDP можно восстановить на временное хранилище и запустить машины отключенными от сети, чтобы убедиться, что ОС запускается и приложения работают.
7. Поддержка "подмораживания" файловых систем Linux.
Для Windows-систем уже давно есть quiescence-скрипты, которые подмораживают операции с данными ВМ, для которой происходит резервное копирование. Для Linux это появилось в версии VDP 6.0 (функция отключена по умолчанию).
8. Поддержка Storage vMotion и Storage DRS в целевом хранилище.
Ранее при перемещении реплики средствами Storage vMotion требовалась полная ресинхронизация ВМ, а в версии VDP 6.0 перемещение машин между серверами и хранилищами отслеживается, и процесс полной синхронизации не запускается.
Больше подробностей о возможностях vSphere Data Protection 6.0 можно узнать из вот этого документа.
На сайте проекта VMware Labs, про который мы регулярно пишем, появилась очень полезная утилита VM Resource and Availability Service (vRAS). Она позволяет провести анализ "что если" (what-if analysis) в плане последствий для инфраструктуры при различных отказах.
Вы можете симулировать отказ одного или нескольких хостов VMware ESXi в кластере, чтобы узнать:
сколько виртуальных машин будут гарантированно перезапущены на хостах кластера HA
сколько машин не смогут запуститься, так как не хватит емкости выживших хостов
сколько машин будут испытывать нехватку вычислительных мощностей и будут работать не в полную силу после рестарта на других хостах
Последний пункт особенно важен для тех инфраструктур, где у машин не установлен параметр Reservation, то есть администраторы знают, что машины перезапустятся в случае сбоя все, но не знают, сколько из них будут испытывать проблемы с производительностью.
Очевидно, что данная информация позволит вам сделать выводы о текущей надежности виртуальной инфраструктуры и принять решение о вводе в строй дополнительных мощностей.
Кстати, VM Resource and Availability Service - это не отдельная утилита, а сервис на стороне VMware. Чтобы начать его использовать, нужно:
Как вы знаете, вчера компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, но нас больше всего заинтересовала технология непрерывной доступности VMware Fault Tolerance.
Ранее никто не воспринимал технологию Fault Tolerance всерьез, поскольку она была доступна только для виртуальных машин с одним vCPU, а такие машины, как правило, не делаются для бизнес-критичных приложений, для которых, собственно, технология Fault Tolerance и создавалась.
Теперь VMware Fault Tolerance в VMware vSphere 6.0 полноценно доступна для виртуальных машин с четырьмя vCPU и 64 ГБ оперативной памяти. И все это поддерживается в производственной среде.
Какие преимущества дает VMware FT в vSphere 6.0:
Непрерывная доступность и полное сохранение данных ВМ в случае отказа хоста ESXi.
При отказе не разрывается TCP-соединение.
Срабатывание Fault Tolerance полностью прозрачно для гостевой системы.
При сбое хоста происходит переключение на новую первичную ВМ, при этом на другом хосте автоматически поднимается новая резервная ВМ.
Что нового в Fault Tolerance 6.0:
Теперь технология непрерывной доступности VMware Fault Tolerance поддерживает виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
Fast Check-Pointing - новая технология, предназначенная для поддержания исходного и резервного узла в синхронном состоянии, пришедшая на смену технологии "Record-Replay".
Поддержка технологии горячей миграции как для Primary, так и для Secondary-узла.
Возможность резервного копирования виртуальных машин, защищенных с помощью FT, технологией vStorage APIs for Data Protection. То есть, для таких ВМ теперь работет Veeam Backup and Replication.
FT в vSphere 6.0 поддерживает новые типы дисков, такие как EZT, Thick или Thin Provisioned. Для vSphere 5.5 и более ранних поддерживаются только диски типа Eager Zeroed Thick.
Возможность создания снапшотов виртуальных машин, защищенных FT.
Новая версия FT поддерживает отдельные копии файлов ВМ (.vmx и .vmdk) для каждой машины, чтобы защитить машину не только от сбоев хоста, но и от сбоев хранилища, которые могут произойти одновременно со сбоем хоста. Файлы Primary и Secondary VM могут быть на разных виртуальных хранилищах.
Но по-прежнему, для Fault Tolerance остаются следующие ограничения:
На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
Обязательно потребуется адаптер 10 Gb. Его можно разделять между различными типами трафика средствами NetIOC.
Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.
Как и раньше, технология VMware HA полностью поддерживается:
Для наглядности есть вот такая табличка, описывающая отличия от предыдущей версии FT:
Надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.
Ну и помните, что VMware Fault Tolerance на защитит от сбоя на уровне приложения - если он произойдет в основной ВМ, то будет и в резервной ВМ, поскольку машины синхронизированы на уровне исполнения инструкций в процессорах.
Многие из вас знают про решение VMware Virtual SAN, представляющее собой средство для создания отказоустойчивых кластеров хранилищ на базе локальных дисков серверов VMware ESXi. Но это всего лишь средство для хранения и обеспечения отказоустойчивости виртуальных машин, а можно ли все пространство хранения в небольшой компании организовать полностью на базе локальных дисков серверов и управлять ими из одной точки?
Компания Nexenta считает, что можно, предлагая пользователям VMware vSphere и VMware Virtual SAN продукт NexentaConnect, позволяющий создавать NFS и SMB ресурсы для размещения данных виртуальной среды и пользователей на локальных дисках хост-серверов.
NexentaConnect это надстройка над Virtual SAN, которая предоставляет следующие возможности централизованно управляемого хранилища:
Экспорт файловых шар по протоколам NFSv3, NFSv4 и SMB 2.1.
Оптимизированный кэш на чтение, размещенный на стороне хост-серверов.
Техники сжатия данных и дедупликации.
Быстрая настройка прямо из vSphere Web Client.
Совместимость с VMware HA и DRS.
Интеграция с доменом AD (поддержка AAA и Kerberos).
Использование преимуществ Virtual SAN.
NexentaConnect состоит из следующих компонентов:
Плагин для vSphere (как для Web Client, так и для vSphere Client).
NexentaConnect Manager – виртуальный модуль (Virtual Appliance) на базе Ubuntu Linux (64 Bit), предоставляющий сервисы управления решением, такие как мониторинг, планировщик событий, база данных, обслуживание операций и т.п.
NexentaConnect Filers – это компоненты, реализующие, собственно, экспорт сетевых шар. Развертываются автоматически по одному на кластер Virtual SAN в момент создания первой общей папки.
Особенности файлеров:
Отдельная файловая система, составленная из виртуальных дисков VMDK по 2 ТБ (для каждой из политик хранения). 2 ТБ - это для того, чтобы обеспечить поддержку со стороны VMware VSAN. Всего можно объединить до 30 VMDK на файлер.
Размер блока 128 КБ.
Развертывание при первом обращении - масштабирование пространства хранения по требованию.
Развертывание как Thin provisioned, так и в режиме заранее аллоцированного пространства.
Параметры файлеров:
ОС Ubuntu Linux (64 Bit)
4 vCPU
16 GB RAM
Минимум 2 виртуальных диска (до 30)
Объем диска до 2 TB
2 сетевых адаптера
Достоинства продукта:
Сжатие данных алгоритмом LZ4 в реальном времени с небольшой нагрузкой на CPU.
До 500 MB/s на компрессию (на ядро).
До 1.5 GB/s на декомпрессию (на ядро).
Дедупликация нулевых блоков.
Дедупликация данных в режиме Tech Preview (полноценная будет во второй версии).
Требования для развертывания NexentaConnect:
VMware vSphere 5.5 или выше
VMware vCenter Server 5.5 U1 или выше (Windows и Linux)
ESXi 5.5 U1 или выше
Кластер VMware vSphere с установленным Virtual SAN
VMware vSphere Web Client
VMware HA (опционально)
Службы каталога (Directory Services - опционально)
Microsoft Windows Active Directory 2008 R2 или выше
VMware vCenter Server 5.5 U1 или выше
DNS
DHCP
NexentaConnect - это еще один способ построить Scale-Out файловый сервер (то есть масштабирующиеся по требованию службы хранения). Например, это востребованной в инфраструктуре виртуальных ПК предприятия, где требуется хранить не только виртуальные машины, но и данные их пользователей.
Об одном из подобных решений - StarWind Virtual SAN - мы регулярно пишем (сейчас это лучшее решение на рынке). Вот тут, например, мы писали про документ о построении инфраструктуры файловых сервисов на базе StarWind.
Добавим, что решение NexentaConnect доступно не только для инфраструктуры VMware vSphere, но и для Citrix XenServer (пока в бете). Больше подробностей о продукте можно узнать вот на этой странице.
Суть бага заключалась в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.
Проблема была обнаружена в начале ноября прошлого года, но только сейчас компания VMware пофиксила этот баг. Описание проблемы и решений можно найти в KB 2090639.
Zip-файлы патчей можно импортировать через VMware Update Manager:
/p>
Напомним, что для решения проблемы без патчей, надо "перещелкнуть" Changed Block Tracking на хосте ESXi (как это сделать - тут и в KB). Старые бэкапы, понятное дело, останутся невалидными. Следующий бэкап после повторного включения CBT всегда будет полным.
Интересно, что для VMware vSphere 4.x никаких патчей на эту тему выпущено не было (Currently, there is no resolution for ESXi 4.x.).
Отметим также, что компания Veeam уже давно выпустила решение этой проблемы. Пользователям Veeam Backup and Replication 8 вообще ничего делать не нужно - там эта проблема уже решена.
Как вы знаете, после запуска виртуальной машины на платформе VMware vSphere, в папке с машиной создается файл *.vswp, который предназначен для свопирования памяти ВМ в критической ситуации. Если у машины проявляется нехватка памяти на хосте VMware ESXi, и она не получает ее через механизм Memory Ballooning, то страницы памяти начинают сбрасываться в этот vswp-файл. Это самая плохая ситуация, так как структурная организация этого файла и то, как понимает своп операционная система, две большие разницы, а значит скорость работы существенно замедляется не только из-за того, что работа идет с диском вместо RAM, но еще и уходит время на поиск нужных страниц.
Соответственно, если у машины 4 ГБ оперативной памяти, то размер vswp-файла также 4 ГБ:
Если мы меняем Memory Reservation для виртуальной машины, то ее файл подкачки уменьшается на величину этого резерва - так как физическая память закрепляется за машиной и не возникнет условий, когда эту часть потребуется свопировать.
Но если сделать Memory Reservation для работающей ВМ (в данном случае 2 ГБ), то размер файла подкачки останется прежним:
Для того, чтобы vswp-файл уменьшился на величину Memory Reservation, надо перезагрузить ВМ - тогда он станет размером 2 ГБ:
Напомним, что у выключенной машины vswp-файла нет.
Но что если у включенной машины убрать (или изменить) Memory Reservation? Все просто - он автоматически увеличится до размера незарезервированной памяти ВМ. Убираем резерв в 2 ГБ и файл вырастает до 4 ГБ:
Ну и напомним формулу:
Swap (.vswp) file size = VM Configured Memory – VM reserved memory
На многим из вас известном сайте VMware Labs появилось интересное мобильное приложение для смартфонов на базе Android - vMaxGuide. Оно позволяет посмотреть информацию о максимальных конфигурациях различных компонентов виртуальной инфраструктуры VMware vSphere.
На данный момент vMaxGuide предоставляет информацию о максимумах для следующих платформ:
VMware vSphere 5.5
VMware vSphere 5.1
VMware vSphere 5.0
Также в сравнениях участвуют различные версии виртуального аппаратного обеспечения (Virtual Hardware). Там где максимумы могут быть достигнуты только при определенных условиях, соответствующие пункты помечены символом "*".
Инсталляция и использование vMaxGuide:
Кстати, эта штучка может быть хорошей шпаргалкой на экзамене по VMware VCP!)
Осенью мы писали о том, что компания VMware планирует отключить технологию Transparent Page Sharing (TPS) в новых релизах платформы виртуализации VMware vSphere. Напомним, что TPS - это механизм поиска и удаления дубликатов страниц памяти в целях экономии физического пространства RAM (вместо самой дублирующейся страницы хранится только ссылка на нее).
Технологию TPS было решено прекратить использовать по двум причинам:
Использование в современных ОС больших страниц памяти (large memory pages) размером в 2 МБ делает намного менее вероятным появление дубликатов.
Использование одной копии страницы памяти несколькими ВМ создает потенциальные проблемы безопасности.
На данный момент статус отключенности TPS по умолчанию на хостах VMware ESXi таков:
В ESXi 5.5 U2d, запланированном на первый квартал 2015 года, TPS будет отключен.
В ESXi 5.1 U3, выпущенном 4 декабря 2014 года, TPS уже отключен.
В ESXi 5.0 U3d, запланированном на первый квартал 2015 года, TPS будет отключен.
Однако не стоит сбрасывать TPS со счетов - возможно, если вы используете старые ОС (Windows 2003) и инфраструктуру VDI на базе старых клиентских ОС, TPS сможет сэкономить вам какое-то количество памяти (если безопасность TPS вас не особенно заботит). Ну и напомним, что TPS отключена только для межмашинного взаимодействия и продолжает работать для внутримашинного.
Для этого в VMware сделали скрипт Host Memory Assessment Tool.ps1, который показывает количество памяти на хостах, которую можно сэкономить с помощью TPS.
Вот что он делает:
Соединяется с vCenter и определяет хосты ESXi
Позволяет включить SSH на хостах
Генерирует отчет об обследовании на экономию по TPS
Можно экспортировать результаты в CSV
Можно снова включить SSH, если нужно
Пока скрипт позволяет указать только одну пару логин-пароль на хостах ESXi, но надеемся это будет исправлено в следующих версиях.
Здесь вот какие значения в колонках:
Total Host Memory – объем физической памяти хоста (доступной vmkernel).
Host Mem Saved via TPS – объем памяти, которая сэкономлена TPS.
Host Mem Saved via TPS Zero Pages – объем памяти, которая экономится на нулевых страницах. Фактически такая экономия не актуальна для большинства случаев, так как сэкономленные нули означают, что недостатка ресурсов не наблюдается.
Potential Host Mem Savings Lost – а вот эта экономия уже на реально используемых страницах. Объем, указанный тут, показывает сколько можно потерять, отключив TPS на хосте.
Host Free Mem – объем свободной оперативной памяти (по данным vmkernel). Если свободной памяти меньше, чем значение в предыдущей колонке, то при отключении TPS будет своппинг.
Вот такая штука, можно проводить эксперименты (особенно полезно это будет для крупной инфраструктуры). Скрипт безопасен для памяти хостов, так как использует режим доступа к памяти только для чтения.
После запуска скрипта вам может потребоваться отключить или включить Transparent Page Sharing на хосте ESXi. В этом случае вам пригодится KB 2097593.
В прошлой статье мы рассказали об основах применения решения Symantec Data Center Security для защиты центров обработки данных. В этой статье пойдет речь о втором продукте из набора Data Center Security: Server Advanced. Ряд производителей безагентских антивирсуных решений для VMware, понимая ограничения возможностей API vShield Endpoint, - выпускают легкие агенты, которые позволяют лучше защищать виртуальные машины...
Как знают многие администраторы VMware vSphere, есть такое удобное средство vSphere Management Assistant (vMA), которое представляет собой виртуальный модуль (готовую виртуальную машину), средствами которой очень удобно управлять скриптами, исполняемыми на нескольких хостах VMware ESXi через интерфейс ESXCLI или Perl.
При выполнении различных сценариев на Linux-машине vMA иногда требуется создать задачу планировщика (крон-таску), чтобы запустить скрипт в назначенное время. Ниже мы опишем, как это нужно делать.
1. Чтобы запускать скрипты без аутентификации, нужно добавить хосты ESXi в vi-fastpass. Вы можете добавить только хосты ESXi, либо хост vCenter Server (или всех их). Используйте команду vifp addserver в интерактивном режиме (конфигурация сохраняется при перезагрузках):
4. Если крон-таска упадет, то вывод ошибок будет направляться сюда:
/var/mail/vi-admin
Вывод ошибки может быть таким:
Can’t load ‘/usr/lib/perl5/site_perl/5.10.0/libvmatargetlib_perl.so’ for module vmatargetlib_perl: libtypes.so: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/DynaLoader.pm line 203.
at /usr/lib/perl5/site_perl/5.10.0/VMware/VmaTargetLib.pm line 10
Compilation failed in require at /usr/lib/perl5/site_perl/5.10.0/VMware/VIFPLib.pm line 9.
BEGIN failed–compilation aborted at /usr/lib/perl5/site_perl/5.10.0/VMware/VIFPLib.pm line 9.
Compilation failed in require at /home/vi-admin/graphite/esxi-perf-graphite.pl line 5.
BEGIN failed–compilation aborted at /home/vi-admin/graphite/esxi-perf-graphite.pl line 5.
Это значит вы некорректно добавили путь к библиотеке (/opt/vmware/vma/lib64:/opt/vmware/vma/lib).
Если же вы получаете вот такую ошибку:
“Server version unavailable at ‘https://[host]:443/sdk/vimService.wsdl’ at /usr/lib/perl5/5.10.0/VMware/VICommon.pm line 545.”
Это из-за непрошедшей SSL-аутентификации. Если у вас нет валидных SSL-сертификатов, отключите авторизацию через SSL в вашем скрипте:
В блоге joshodgers.com появилось пять интересных статей о том, как правильно виртуализовать почтовый сервер Microsoft Exchange на платформе VMware vSphere.
Тут обсуждается необходмый объем памяти. Не рекомендуется использовать Memory Overcommitment (то есть, часть ресурсов надо всегда держать свободными), а вот Memory Reservations предлагается устанавливать в 100% - таковы рекомендации для бизнес-критичного сервиса.
К выделенной памяти виртуальным машинам рекомендуется прибавлять как минимум 25% требуемой емкости памяти хоста ESXi. То есть, если у вас машина с 96 ГБ RAM, то хост должен иметь как минимум 128 ГБ физической памяти. Также рекомендуется сайзить машину с Exchange в пределах одного NUMA-узла.
Тут основная рекомендация - держать машины с ролями MBX / MSRна одном хосте в целях быстродействия (средствами хост-групп), а также настроить их восстановление в случае сбоя также на один хост. Также уровень автоматизаци миграций ВМ в кластере рекомендуют выставить как "Fully Automated" (а Migration Threshold как 3).
В этой части цикла описываются рекомендуемые настройки механизма VMware HA.
В этой статье, пожалуй, больше всего дается практических советов и рекомендаций по настройке VMware HA в кластере высокой доступности для виртуальных машин с Exchange на борту.
Многие администраторы VMware vSphere знают про файлы vSphere Installation Bundle (VIB), которые позволяют распространять программные компоненты для серверов ESXi. Например, с помощью VIB-файлов устанавливаются кастомные драйвера (и куча своих VIB есть для каждого кастомизированного образа, например, HP).
На днях была выпущена утилита VIBSearch, которая может оказаться полезной многим администраторам в вопросах поиска и сравнения версий VIB-пакетов на разных хостах ESXi.
Утилита представляет собой скрипт на PowerShell c GUI, в котором можно ввести параметры доступа vCenter и поискать на серверах ESXi конкретный VIB-пакет (по вхождению строчки в его название).
С чем тестировался скрипт:
PowerShell 4.0
PowerCLI 5.8 Release 1
Для командлета Out-GridView нужен компонент PowerShell ISE. Для его установки нужно использовать следующие команды PowerShell:
Многие пользователи, которые начинают пользоваться средствами виртуализации от VMware, рано или поздно задаются вопросом - как создать копию виртуальной машины (клонировать её) в бесплатной версии VMware ESXi. Если у вас есть коммерческое издание VMware vSphere и сервер управления vCenter, то клонировать ВМ можно просто из контекстного меню машины:
Однако все несколько сложнее, если у вас бесплатная версия VMware ESXi Free (он же vSphere Hypervisor). Тут можно пойти вот какими путями:
Это средство позволяет вам создать виртуальную машину на целевом хосте (а именно на нашем бесплатном ESXi), установив сам Converter внутрь машины, и создать ее клон как физической системы. При этом в процессе клонирования ("миграции") сохраняется обе системы, а различные настройки, такие как размеры виртуального диска, имя системы и прочее, можно кастомизировать.
2. Использовать софт для резервного копирования и восстановления.
Сначала создаем резервную копию машины, а потом восстанавливаем ее параллельно с уже существующей ВМ.
3. Можно просто скопировать виртуальную машину и ее диск.
Первый вариант данного способа прост - копируете папку с ВМ (для доступа к файловой системе ESXi можно использовать WinSCP или FastSCP). Далее добавьте ВМ в окружение ESXi файл *.vmx через контекстное меню и пункт "Add to inventory":
Второй вариант - это использование утилиты vmkfstools. Она позволяет клонировать диски виртуальных машин, задавая различные параметры целевого диска. Например, вот эта команда создает клон виртуального диска, но целевой диск будет в thin-формате (то есть растущим по мере наполнения данными):
С помощью этой утилиты можно много чего делать, более подробно о ней написано в KB 1028042. Далее создаем новую ВМ и подцепляем к ней полученный виртуальный диск. Не забудьте поменять имя машины и сетевую идентификацию!
Есть еще способ сделать клон ВМ с помощью VMware vSphere Management Assistant (vMA) и vSphere CLI (vCLI) как написано в KB 1027872, но он требует развертывания vMA и не стоит заморочек ради клонирования одной ВМ. Но для регулярного клонирования машин - обязательно изучите эту KB.
Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.
Надо сказать, что обеспечение надежности сервера vCenter, работающего в виртуальной машине (а сейчас уже мало кто ставит его в физической), начинается с обеспечения доступности и дублирования компонентов, которые находятся "под ним", а именно: хост-сервер ESXi, источники питания, хранилища, сетевые подключения и т.п.
Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".
Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:
Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.
Понятно, что оба этих компонента могут быть как на одном сервере (для небольшой инфраструктуры), так и в разных машинах, когда требуется производительная база данных (например, в Enterprise-окружениях).
Если у вас большая виртуальная инфраструктура, где есть множество управляющих компонентов, то вы можете выделить отдельный кластер из трех и более хостов чисто под эти нужды.
Но чаще всего у вас есть просто одна или максимум две виртуальные машины - одна под vCenter, вторая - под его базу данных.
Доступность Compute Node
Это раздел включает в себя доступность следующих комопнентов:
vCenter Single Sign-On services
vCenter Inventory Service
vCenter Server
vCenter Server management Web service
vSphere Web Client
Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:
Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.
Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.
Выглядеть это может примерно вот так (только помните, что в случае такй настройки, виртуальная машина может впасть в цикл бесконечных перезагрузок).
Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.
Доступность Data Node
Тут VMware приводит следующие рекомендации:
Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.
Для тех из вас, кто по каким-либо причинам еще не обновился на vSphere 5.5, полезная новость - вышло обновление VMware vSphere 5.1 Update 3 (ESXi и vCenter), которое уже доступно для загрузки. Новых возможностей не появилось, зато была добавлена поддержка новых гостевых ОС и исправлены некоторые значимые баги.
Итак, что нового в ESXi и vCenter 5.1 U3:
Поддержка новых БД vCenter Server - теперь можно использовать
Oracle 12c и
Microsoft SQL Server 2014
Поддержка новых браузеров для Web Client 5.1 Update 3. Теперь поддерживаются:
Internet Explorer 8 / 9 / 10/ 11
Firefox 31 / 32 / 33
Google Chrome 36 / 37
Поддержка новых гостевых ОС. Полный список поддерживаемых ОС можно посмотреть тут.
RSS
